Super Audio

home *** CD-ROM | disk | FTP | other *** search

/ Super Audio / Super Audio.iso / replay / _armovie / documents / tocapture < prev next >

Wrap

Text File | 1997-11-10 | 10.4 KB | 189 lines

Requirements for an Acorn Replay Capture program Video Data (1) The Acorn Replay compressors take (any) Acorn Replay files as their input data. There are 6 possible forms of (uncompressed) input data: - 15 bit rgb pixels: each pixel is 5 bits of red, green and blue (red in bits 0-4, green in 5-9, blue in 10-14, bit 15 zero). Pixels recorded in successive half words. ARMovie file compression format 2, pixel depth 16. - 15 bit YUV pixels: each pixel is 5 bits of Y (luminance), U and V chrominance signals (Y in bits 0-4, U in 5-9, V in 10-14, bit 15 zero). Pixels recorded in successive half words. ARMovie file compression format 2, pixel depth 16 with YUV in the pixel depth field. - 20 bit YYUV pixel pairs: two pixels recorded with two 5 bit luminance signals and one set of common U and V chrominance signals (Y1 in bits 0-4, Y2 in bits 5-9, U in bits 10-14, V in bits 15-19). Pixels recorded in successive 20 bit values: 160 bits (5 32 bit words) represents 16 pixels and is a basic recording unit. ARMovie file compression format 3, pixel depth 16 with YUV in the pixel depth field. - 8 bit grayscale: one pixel per byte. No compressor yet exists for this data, but files can be played. ARMovie file compression format 4, pixel depth 8. - 30 bit YYYYUV pixel quads: four pixels in a square recorded with individual luminance signals and one set of common U and V chrominance signals, the whole thing held as one word (Y1 in bits 0-4, Y2 in bits 5-9, Y3 (second row) in bits 10-14, Y4 in bits 15-19, U in bits 20-24, V in bits 25-39, bits 30 and 31 zero). ARMovie file compression format 5, pixel depth 16 with YUV in the pixel depth field. - 90 bit YYYYYYYYYYYYYYYYUV pixel sixteens: 16 pixels in a square recorded with individual luminance signals and one set of common U and V chrominance signals, the whole thing held as three words (Y1 to Y6 in bits 0-29 of word 0, Y7 to Y12 in bits 0-29 of word 1, Y13 to Y16 in bits 0-19, U in bits 20-24, V in bits 25-29 of word 2, all bits 30 and 31 zero). ARMovie file compression format 6, pixel depth 16 with YUV in the pixel depth field. If possible, avoid the pedestals usually found on systems - occupy the full 0-31 range of the components (or 0-255 for grayscale). Gamma correction is assumed to have been done (so that equal increments in the input range are approximately equal perceptual increments). Frame size is recorded in the ARMovie file header: although ARMovie files can have arbitary numbers of pixels in a frame, the Acorn Replay Moving Line compressor expects the frame to be a multiple of 8 pixels horizontally. 160x128 or 160x120 are typical sizes: these play back at 1/4 screen VGA. The space used for the formats is: format bits used Bytes used per per pixel frame at 160x128 pixel multiples x y 2 16 40960 x1 y1 3 10 25600 x2 y1 4 8 20480 x4 y1 5 8 20480 x2 y2 6 6 15360 x4 y4 Acorn can supply sample ARMovie files in all formats if required. Acorn can also supply an !ARMovie directory containing decompressors (with source) for types 2, 3, 4, 5 and 6. (2) All frames should be image processed the same way. Dithering of some form is recommended when converting from 8 bits per sample to 5 bits per sample, Floyd Steinberg dithering (or some other scheme having low error propagation values) is preferred, but dithering to the right pixel is acceptable - it results in lower compression factors, but not as bad as no dithering - provided the input data can stand the slight smearing that results. With any of the YUV formats, it is possible to dither only the Y signals. Sharpening is not recommended since it results in lower comression factors. Scaling by linear interpolation (equal area weighting or other filtering schemes) is recommended to produce images of the required size. Point sampling is permitted but *not* recommended. Frame sizes should be a multiple of 8 pixels horizontally. (3) The ARMovie file is usually called "Capture". It is recommended that it is a multiple of 50 (60) frames in length (or a multiple of 25 frames in length if recorded at 12.5fps). If you wish to allow for immediate play back of the captured data, it may be necessary to restrict the chunk size to less than 1MByte (i.e. 1 second chunks instead of the more usual two seconds): the !ARMovie Player provided by Acorn uses double buffered chunk IO and thus loads two chunks at once: a 25 fps 160x128 capture in format 2 with 2 second long chunks is 2 MByte per chunk and can only be played on machines with more than 4MBytes free. (4) For mastering a movie at both 25fps and 12.5fps (30fps and 15fps if you happen to be a 60Hz provider), all frames must be recorded. The Acorn Replay compression software will make a 25fps movie using all frames and a 12.5fps movie using only the even numbered frames. (5) For mastering a movie at only 12.5fps (15fps) it is possible to record only the even (or odd - your choice) frames. It need only be a multiple of 25 (30) frames in length. (6) The !ARMovie Player program can play format 2, 3, 4, 5 and 6 directly, providing the source media is fast enough. This gives direct evidence of sound sync etc. If the source isn't fast enough, then use -speed to slow the play rate down (e.g. -speed 0.5). (7) Writing the ARMovie file. Note that the last chunk in the movie need not have the same number of frames in it as all the other chunks: just write the catalogue entry correctly (the sound can be cut immediately by an appropriately short catalogue entry). The various pointers in the header of the ARMovie file all need to be filled in properly or it doesn't work! Two fields in particular are the number of chunks and the catalogue of chunk offsets. (a) If you know the length (say, in seconds) in advance of making the recording, then the number of chunks field can be written directly the header is written (note that its the number of chunks -1: a 2 second long movie with 2 second chunks has 0 s the number of chunks). If you are not recording the sound, the number of bytes in a chunk will be constant and the catalogue can also be written directly, with each catalogue entry calculated to contain what will be written. Then write the data. If the sound is being recorded, the number of samples per sound grab may well vary (especially if approximating an irrational frequency like 1/72uS): the catalogue needs to be written after the chunks have been written, so make enough space (e.g. in the wimpslot) to keep the entire catalogue in RAM; write all the chunks, then write the catalogue after the chunks, then go back to the start of the file and ammend the catalogue pointer. (b) if you don't know the length, then the strategy is similar to (a) above: write the header, write all the chunks keeping the data which will be used to construct the catalogue in RAM, finish recording by writing the final chunk, write the catalogue, then go back and ammend the header to have the correct number of chunks and correct catalogue pointer. Sound Data (1) It is required that the sound sampler's notion of time and the video sequence's notion of time agree: otherwise the sound will start in sync with the video and drift out as the clip is played. This can be achieved either by extreme accuracy of player and sampler (both to within 1/10 second after 1000 seconds, say) or by GENLOCKing the player and sampler togther. Since most professional video equipment has GENLOCK input capability, Acorn recommend that the sampler's clock is divided down to produce a VSync-like signal to which the video source is GENLOCKed. (2) Sound capture must be started in frame sync with the video sequence. The sound sample must be continuous and extend to the end of the video sequence (preferably just beyond the end!). There should be no AGC or other systems used to unnaturally alter the sound level. (3) Sound data should be oversampled at at least twice the desired replay rate: for example, if the replay rate is to be 10,000Hz, then the sample should be made at at least 20,000Hz, with the data resampled to 10,000Hz. Alternatively, you can capture at the desired replay rate using one of the modern over-sampling-with-dsp-decimation devices which does it all for you. (4) Sample rate (and thus replay rate) must be specified precisely - don't say 10,000Hz when you mean 10,000.25Hz!!!! Precise numbers of uS can also be represented: 72 means 72 uS rather than 72Hz (true up to 255 uS). (5) The replayed data uses VIDC's exponential format for greater dynamic range. Input data should be 16 bit linear or 8 bit exponential (bytes). 16 bit linear data can be converted to 8 bit exponential format with the program "Convert" or to ADPCM 4 bit format with the program "s16toa" (see 'ToRunDiffer'). 8 bit linear data should be left alone: Replay will convert it to exponential format as the data is replayed - in order for this to happen correctly, the movie header MUST contain the word "linear" in the number of bits entry for sound. (6) Although the sound data should be held in the ARMovie "Capture" file, it may be hard to do this if sound and video are being recorded seperately. So an 8 bit sound sample can also be held as a different ARMovie file, or as one RISC OS file "Sound" at the top level of the hierarchy of files. 16 bit files are called "Samples". ADPCM files are called "ADPCM". These files may also exist if sound is derived from the captured sound before being made into the final movie. Other Data (1) A header containing all the textual information for the ARMovie (AE7) file produced by the compressors must be supplied and called "1Header" or "2Header". This file is especially important if the ARMovie "Capture" file contains no sound, since it is the reference for it. The chunk size in these header files should be 2 seconds. (2) A default sprite called "Sprite" must be supplied. This should contain an image the same size as the movie in mode 13 pixels (the sprite can be mode 15 or mode 28 if required). (3) Acorn have converters for old captured data. These programs are basically modified compressors which work on old capture trees, writing out Images which can then be Joined by old Joiners to make type 2 or type 3 format ARMovie files. Please contact Acorn if you need these, however we don't consider them 'user friendly'!